项目需要进行阶段性压力测试，所以想模拟真实的正式环境，所以是直接使用域名访问进行压力。整个请求链路大概如下：

就是Jmeter压力测试的结果的TPS很低，基本在200TPS甚至100TPS以下，但是机器的配置非常高（32C + 64G）。当时第一次遇到这种现象很懵逼，没办法，第一次一个人从0做一个系统，压力测试。第一次遇到的现象是直接上不去TPS，空接口也上不去；第二次遇到是TPS能瞬间上去很高，但是立马掉下来，稳不住，但是空接口没问题，可以继续稳住。

想了很久都没有找到原因，只能本地跑起来代码，看看情况；当时的思路有两个，一个是代码太烂了，第二个是配置不对导致的。第一个原因的解决方法：找到一个工具去监控代码的卡点；第一个原因的解决方法：不停的改变配置，重新压测看结果，配置包括：Tomcat的配置和代码线程池的配置，有人可能会说，为啥没有考虑JVM的配置，原因是压测测试只压测一个接口的情况并且数据是同一份，JVM不太可能会是瓶颈，当然如果该接口存在很多成员变量缓存除外。

在当时找工具中找到JProfier，结果发现代码的确存在卡点，但是并没有Jmeter反馈的那么慢，并且最后定位的卡点是Redis的客户端取缓存的地方会比较慢，有可能会出现取一个Key需要几十毫秒的情况。解决的方法自然第一个想到使用Pipeline解决，之前循环取Key变成批量取Key。

老代码的伪代码如下：

新伪代码如下：

最后压测结果：利用Pipeline并没有很明显的改善。

后来用getKeys命令，发现的确有很明显的提升，所以后来批量取Key操作全部换成getKeys命令。其实后来发现这样做是有很多弊端的，包括Pipeline。 弊端就是：在Redis集群环境下就没法这样了，需要改动很多代码。后来据我了解，getKeys命令尽量不用，因为现在的应用基本后面都会走向集群化的。并且Redis的性能很高，网络也基本是内网，所以RRT时间影响并不会很大，循环取Key也不会相差很大的。如果真的遇到热Key应该用其他方案解决。

因为本人那时候是单机环境所以就没动了，还是使用了getKeys命令。到此业务的卡点基本解决了。但是TPS提升并不会非常大，没有数量级的上升。依旧是不正常的情况。

配置也各种尝试都没有什么很大变化，所以说明跟配置，大家也是知道的，配置只有给的不会太小的情况，基本影响不是很大。

空接口也会出现同样的问题，说明代码影响不是很大，所以至此遇到问题不要忙于去操作，应该先去分析问题，当时太年轻，一顿操作猛如虎，最后结果两百五。这个现象至少说明是代码的Controller层之前有问题，之前有问题肯定就是拦截器的代码有问题，或者SpringMVC框架和Tomcat有问题；后两者使用的都是稳定版，大概率不应该会出现这种BUG。那就是拦截器代码有问题了，当时为了调试方便有一个AOP会打印所有日志的请求和响应日志。也有人提出会不会是卡在IO上，但是我当时认为代码没有直接IO操作忽略掉了日志的IO操作，并且我认为日志框架默认是异步打印的，不会这么蠢的吧；后来实在没有思路了，我尝试关闭日志试试，发现TPS瞬间上去了。心中一万个草泥马，日志框架竟然不会异步去打印日志，而是同步打印日志。到此问题得到解决。当时使用的是Logback日志，普通的配置是不会异步打印，需要额外套一层异步打印配置，各位看官如果使用的也是Logback日志，也需要注意这点。异步配置，各位可以百度一下。

这次的现象很不一样，这次是会上去，但是会掉下来，造成一种达到系统瓶颈的假现象，但是系统资源却没有满的情况。并且空接口并不会造成这种现象。当时的想法是系统已经到了瓶颈，但是仔细分析又感觉不对，为什么呢？因为我用Arthas工具分析到Controller的方法耗时是会出现耗时超过1s+的情况，但是并不会出现Jmeter显示的数据，接口响应中位数到达几十秒的情况，我一度怀疑Jmeter有BUG，但是找了很久也没有人分享有这个问题。后来项目组招了一个大佬过来，我请求他的援助，他也是分析了两三天，最后没有找到原因，但是他的经验也认为这个压测数据肯定有问题。但是此时的我，在他的分析过程中，学到了不少之前没有的经验。所以视野也更宽阔。所以后来我再次接手，我发现一个规律就是Controller的方法用Arthas工具分析不会卡，但是Tomcat的access日志也显示接口耗时严重，跟Jmeter的数据是一致的。于是我跟大佬反馈了这个现象。大佬瞬间跟我一起用Arthas再次监控看系统情况，系统一切正常：网络、IO、JVM；但是看线程情况，发现数据不正常，发现大量的线程在阻塞状态，于是选其中几个线程抽看一下，线程阻塞在哪里，发现阻塞在同一个地方。阻塞在一个拦截器中加锁操作中。

需要统计用户的在线时长，这是运营很正常的需求。正常业务的做法是：

但是实际情况是：现在的用户退出应用都是直接杀进程，客户端没法捕获这种情况的事件，也就是没法调用退出接口了。还有就是用户不会每次都需要登录，所以进入APP也不一定会调用登录接口。所以设计的方案是使用心跳机制，用户登录和退出都是服务端判断的。做法如下：

因为是集群部署，所以这存在线程安全，就采用了锁机制。使用Redis的分布式锁，每次用户请求接口就会调用如下方法，伪代码如下：

原因到此时找到了，接下来就改代码了，最后商量的方案，是采用无锁方案，加锁一整段代码使用Redis的lua脚本去做。因为Redis是单线程的，所以使用脚本是不存在线程安全问题。然后再次压力测试，单机TPS从之前的100直接上升到3000。

经历这一次我再一次认识了对多线程编程的知识，在高并发环境中，锁竞争导致上下文切换是可能会非常影响性能的。

系统瓶颈问题，需要从多方面去考量，遇到瓶颈问题不要遗漏任何一处代码。

最后，本次回顾因为本人该死的拖延症，所以间隔时间比较久了，整个事件复盘不是很清晰，各位看官多多包涵。